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During  the  three  years  of  the  project  we  developed  our  regression  verifi¬ 
cation  tool  (RVT)  in  various  ways,  which  together  improved  tremendously  its 
functionality,  robustness  and  completeness.  Recall  that  the  main  problem  that 
RVT  addresses  is  that  of  deciding  whether  two  similar  programs  are  equivalent 
under  an  arbitrary  yet  equal  context,  given  some  definition  of  equivalence.  More 
precisely,  given  a  (possibly  partial)  mapping  between  the  functions  of  the  two 
programs,  the  problem  is  to  show  which  of  them  are  equivalent  in  an  arbitrary 
context.  The  basic  definition  of  equivalence  that  we  support  is  called  partial 
equivalence,  which  means  that  two  programs  emit  equal  outputs  given  the  same 
inputs,  or  at  least  one  of  them  does  not  terminate.  For  most  useful  definitions  of 
equivalence  this  problem  is  undecidable,  as  is  the  problem  of  partial  correctness 
(what  most  people  refer  to  as  general  program  verification)  in  general.  The  latter 
is  a  term  suggested  by  T.  Hoare  in  1960’s,  to  denote  the  problem  of  checking  that 
a  certain  condition  holds  at  a  particular  location  assuming  the  program  can  get 
there.  It  can  be  cast  as  a  reachability  problem:  can  the  program  reach  a  certain 
part  of  the  code  that  is  guarded  by  the  negation  of  the  checked  condition?  It  is 
not  difficult  to  reduce  this  problem  to  a  problem  of  proving  partial  equivalence: 
simply  make  the  program  emit  output  ’0’  if  that  part  of  the  code  is  reached,  and 
’1’  otherwise,  and  compare  it  to  a  program  that  only  emits  ’1’.  This  proves  that 
equivalence  is  undecidable  as  well. 

Even  in  cases  that  equivalence  can  be  determined  in  theory  (for  example  when 
there  are  no  loops  and  recursive  calls),  there  are  tremendous  technical  problems 
in  performing  this  task  when  it  comes  to  an  industrial  programming  language 
such  as  C,  because  of  issues  such  as  dynamic  memory  allocation  and  the  ability 
of  programs  to  access  the  memory  with  arbitrary  references.  A  major  part  of 
our  research  is  in  fact  dedicated  to  such  issues:  how  to  enforce  isomorphic  heaps 
at  the  entrance  to  the  two  functions,  and  how  to  check  that  they  are  isomorphic 
at  the  exit  point. 

Many  of  the  technical  details  of  our  progress  in  the  last  three  years  were 
reported  in  my  previous  annual  reports,  so  I  will  only  mention  them  here  by 
title. 

—  Support  for  checking  Mutual  termination.  Two  programs  are  said  to  be  mutu¬ 
ally  terminating  if  they  terminate  on  exactly  the  same  inputs.  RVT’s  ability 
to  prove  mutual  termination  may  expose  termination  errors  introduced  by  a 
new  version  of  the  code.  This  work  has  been  reported  in  the  masters’  thesis 
of  Dima  Elenbogen  [Elel3]  and  in  an  article  [EKS12]. 
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—  A  theoretical  investigation  into  the  possibilities  and  limitations  of  prov¬ 
ing  partial  equivalence  of  multi-threaded  programs.  So  far  this  problem  has 
only  been  studied  for  the  case  of  single-threaded  deterministic  programs. 
We  showed  a  method  for  regression  verification  to  establish  partial  equiva¬ 
lence  of  multithreaded  programs.  Specifically,  we  developed  two  proof-rules 
that  decompose  the  regression  verification  between  concurrent  programs  to 
that  of  regression  verification  between  sequential  functions,  a  more  tractable 
problem.  This  ability  to  avoid  composing  threads  altogether  when  discharg¬ 
ing  premises,  in  a  fully  automatic  way  and  for  general  programs,  uniquely 
distinguishes  our  proof  rules  from  others  used  for  classical  verification  of 
concurrent  programs.  The  results  of  this  work  are  summarized  in  [CGS11]. 
We  recently  also  started  considering  the  effect  of  synchronization  primitives 
and  dynamic  thread  creation. 

—  Support  for  programs  with  Goto  statements.  As  I  reported  last  year  in  some 
detail,  RYT  now  supports  translating  programs  with  goto-statements  into 
one  with  While  loops,  which  can  then  be  handled  in  the  standard  flow  of 
RVT. 

—  We  developed  several  techniques  for  improving  completeness.  The  develop¬ 
ment  of  these  methods  was  driven  by  our  experience  with  checking  real 
programs.  I  describe  these  techniques  in  detail  in  Appendix  A.  They  were 
only  published  thus  far  as  part  of  a  thesis  [Elel3],  and  we  currently  work  on 
an  extended  version  of  [EKS12]  that  will  include  them  as  well. 

We  are  currently  working  on  new  proof  rules,  based  on  computing  weakest 
pre-conditions  expressions,  and  applying  fc- induct  ion.  Some  details  about  this 
effort  is  given  in  Appendix  B. 

Finally,  we  are  currently  in  the  midst  of  improving  RVT’s  capability  to  han¬ 
dle  recursive  data  structures.  Performing  regression  verification  over  programs 
that  incorporate  pointers,  arrays  and  recursive  data  structures  poses  several 
challenges.  When  asserting  the  equality  of  arrays  we  must  assert  the  equality 
of  all  their  members.  When  checking  the  equality  of  structures,  we  must  check 
equality  on  all  of  its  members  recursively.  When  checking  the  equality  of  point¬ 
ers,  asserting  the  equality  of  the  addresses  is  meaningless;  we  must  dereference 
them  and  check  the  actual  value.  When  these  pointers  point  to  a  recursive  data 
structure,  the  comparison  should  be  pairwise  over  all  the  leaves  of  the  structure. 
Many  of  these  issues  were  solved  with  a  tool  called  UNITRV,  built  recently  by 
Daniel  Kroening  based  on  the  infrastructure  of  CPROVER.  This  tool  can  prove 
the  partial  equivalence  of  two  functions,  even  if  their  inputs  include  pointers  to 
recursive  data  structures.  It  effectively  assumes  that  locations  pointed  to  by  an 
equivalent  access  path,  contain  the  same  data.  For  example,  if  both  functions 
access  p  ->  next  ->  next  ->  data,  and  p,  next,  data  are  mapped  to  one 
another  in  the  two  functions,  then  they  read  the  same  value  initially.  We  are 
currently  working  on  fully  integrating  this  tool  into  RVT,  in  order  to  improve 
its  completeness,  and  reach  the  point  in  which  RVT  can  verify  the  equivalence 
of  real  industrial  programs.  So  far  the  issue  of  pointers  was  a  hurdle  in  reaching 
this  point. 


Distribution  A:  Approved  for  public  release;  distribution  is  unlimited. 


To  conclude,  I  would  like  to  thank  the  AF  for  this  generous  grant  with  which 
I  funded  this  research. 
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A  Methods  for  improving  completeness 

No  sound  method  of  proving  mutual  termination  can  be  complete  because  this 
problem  is  undecidable,  but  we  should  strive  to  improve  the  completeness  of 
our  approach.  The  two  major  reasons  of  its  incompleteness  are  related  to  the 
overapproximation  of  the  real  behavior  caused  by  replacing  recursive  calls  with 
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uninterpreted  functions.  Refinement  of  our  uninterpreted  functions  can  solve  a 
few  of  overapproximation-related  issues. 

However,  there  exist  other  reasons  for  the  incompleteness  in  our  approach. 
In  this  appendix  we  will  address  a  few  of  them  that  we  have  coped  with.  Some 
of  them  are  applicable  to  or  refine  the  output  of  the  decomposition  algorithm 
presented  in  a  technical  report  [GS11]  for  verification  of  partial  equivalence.  Such 
improvements  are  valuable  for  proving  mutual  termination  too  because  knowing 
that  some  functions  are  partially-equivalent  can  be  beneficial  for  establishing 
their  mutual  termination. 


A.l  Reducing  prototypes  of  loop-replacing  functions 

Appendix  C  of  [God08]  gives  a  detailed  description  how  loops  are  replaced  with 
functions.  Local  variables  that  are  used  inside  loops  are  part  of  the  interface 
of  the  replacing  function,  even  if  they  are  written-to  before  being  read.  The 
problem  is  that  these  variables  are  local  and,  hence,  receive  a  non-deterministic 
value  and  thus  make  the  uninterpreted  functions  representing  the  loop  return 
different  values.  The  following  example  demonstrates  the  issue. 

Example  1.  Consider  the  pair  of  C  programs  listed  in  Fig.  I1.  Extracting  the 


int  main()  { 

int  main’()  { 

int  y,  x  =  1; 

int  x’  =  1,  y’; 

while  (x  <  10)  { 

while  (x’  <=  9)  { 

y  =  2  +  x; 

y’  =  x’  +  2; 

x  =  y  +  y; 

x’  =  2  *  y’; 

} 

} 

return  x*2; 

return  x’  <<  1; 

} 

} 

Fig.  1.  Two  versions  of  programs  each  of  which  contains  a  loop  with  an  uninitialized 
variable  y  ( y ')  which  is  written-to  before  ever  being  read. 


loops  into  separate  recursive  functions  results  in  the  two  programs  listed  in  Fig.  2. 
When  partial  equivalence  of  (main,  main')  is  verified,  (mainUF ,  main'UF )  are 
generated  as  listed  in  Fig.  3.  The  values  of  y  and  y'  in  (mainUF ,  main'  ), 
respectively,  are  non-deterministic.  Consequently,  not  all  the  arguments  passed 
into  calls  UF(Loop_main_whilel,  Szx,  Szy)  and  UF’(Loop_main_whilel’,  8z x',  Szy') 
are  considered  equal,  because  direct  pointers  are  considered  equal  if  they  point 
to  equal  values.  Thus  those  calls  are  considered  different.  As  a  result,  ( mainUF , 
main'UF )  are  not  considered  call-equivalent.  Hence,  RVT  will  fail  to  prove 

1  Hereafter,  the  syntax  of  C  is  slightly  violated,  for  instance,  by  ending  identifiers  of 
side  1  with  ’. 
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int 

Loop _main_whilel (int  *px, 

int 

Loop_main_whilel’(int  *px\ 

int  *py) 

int  *py’ 

{ 

if  (!(*px  <  10))  return  0; 

{ 

if  (!(*px’  <=  9))  return  0; 

*py  =  2  +  *px; 

*Py’  =  *P*’  +  2; 

*px  =  *py  +  *py; 

*px’  =  2  *  *py’; 

return  Loop_main_whilel(px,  py); 

return  Loop_main_whilel’(px’,  py 

} 

} 

int  main()  { 

int  main’O  { 

int  y,  x  =  1; 

int  x’  =  1,  y’; 

Loop_main_whilel(&x,  &y); 

Loop_main_whiler(&:x’,  &y’); 

return  x*2; 

return  x’  <<  1; 

} 

} 

Fig.  2.  Two  versions  of  programs  from  Fig. 

1  after  elimination  of  their  loops. 

int  mainUF()  { 

int  main'UF()  { 

int  y,  x  =  1; 

int  x‘  =  1,  y’| 

UF(Loop_main_whilel,  &ix,  &?/); 

UF’(Loop_main_wliilel’,  &cx',  &iy' 

return  x*2; 

return  x’  <<  1; 

} 

} 

Fig.  3.  Parts  of  the  program  generated  for  proving  the  mutual  termination  of  functions 
main,  main' ,  defined  in  Fig.  2. 
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m-term(mainu  F ,  main'UF). 

□ 

There  is  no  good  reason  to  include  the  variables  of  loop-bodies  which  satisfy 
the  two  following  conditions,  into  the  argument  list  of  the  functions  that  replace 
the  loop: 

Cl.  before  their  values  are  ever  read,  some  value  is  assigned  into  them,  and 
C2.  they  are  no  longer  used  after  the  body  of  the  loop. 

They  may  become  mere  local  variables  in  the  replacing  functions. 


int  Loop_main_whilel(int  *px)  { 
int  y; 

if  (!(*px  <  10))  return  0; 
y  =  2  +  *px; 

*px  =  y  +  y; 

return  Loop_main_wliilcl(px); 

} 

int  main()  { 
int  y,  x  =  1; 

Loop_main_while  1  (&x) ; 

return  x*2; 

} 


int  Loop_main_wliiler(int  *px’)  { 

int  y’; 

if  (!(*px’  <=  9))  return  0; 
y’  =  *px’  +  2; 

*px’  =  2  *  y’; 

return  Loop_main_whilel’(px’); 

} 


int  main’()  { 
int  x’  =  1,  y’; 
Loop_main_whileT  (&x’) ; 
return  x’  <<  1; 

} 


Fig.  4.  Two  versions  of  programs  from  Fig.  1  after  replacement  of  their  loops  with 
functions  and  reduction  of  variables  y  and  y'  from  the  argument  lists  of  those  replacing 
functions.  See  Fig.  2  for  a  comparison. 


Example  2.  Reconsider  the  programs  given  in  Fig.  1  and  note  that  variable  y 
(y1)  in  function  main  ( main ')  is  initialized  every  time  before  being  read  in  the 
loop-body.  In  fact,  there  is  a  single  execution  path  in  that  loop-body.  Thus,  y  (y1) 
satisfies  condition  Cl.  Moreover,  note  that  it  is  not  used  since  the  end  of  the  loop- 
body,  i.e. ,  it  satisfies  C2  too.  Hence,  py  ( py ')  may  be  reduced  from  the  argument 
list  of  the  loop-replacing  function  Loopjmain-while  1  (. Loopjmainjwhilel' ),  and, 
furthermore,  y  (y1)  may  become  a  local  variable  inside  it  as  listed  in  Fig.  4.  Now 
m-term(main,  main')  can  be  proven. 

□ 

Here  is  a  description  of  the  procedure  we  apply  for  detecting  variables  which 
satisfy  conditions  Cl  and  C2.  Validating  Cl  amounts  to  checking  that  a  variable 
is  initialized  before  being  read  in  every  computation  path  in  the  loop-body  block. 
If  it  passed  the  check,  C2  should  be  validated.  The  latter  validation  is  done  using 
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live-variables  analysis  [Nie85].  If  it  establishes  that  the  variable  has  stopped 
being  a  live  variable  by  the  end  of  the  loop-body,  then  C2  holds. 

Two  simple  intraprocedural  static  analyses  [Hec77]  aid  to  validate  Cl  in  a 
checked  loop-body  block.  The  first  analysis,  which  we  call  Write-  To  (WTJ,  for 
each  node  of  the  control  flow  graph  of  that  block,  finds  variables  that  some¬ 
thing  is  written  to  them  in  all  execution  paths  leading  to  the  node,  includ¬ 
ing  writings  in  this  node  itself.  The  nodes  of  control  flow  graphs  on  which 
we  run  our  analyses  are  expressions  in  C-language.  WT  is  a  flow-sensitive  for¬ 
ward  [FB88,WMM95]  must  [NNH05]  analysis.  Based  on  its  results,  the  second 
one,  called  Read- Uninitialized  (RU),  finds  those  variables  that  may  be  read  be¬ 
fore  something  is  written  to  them,  i.e. ,  detects  potential  reads  of  uninitialized 
variables.  Those  variables  of  the  checked  loop  which  are  not  listed  in  the  results 
of  RU  are  written-to  before  being  read  in  this  loop-body,  i.e.,  satisfy  Cl.  RU  is 
a  flow-sensitive  forward  may  [NNH05]  analysis.  The  both  analyses  are  formally 
defined  in  Tables  1  and  2. 


kill  function 
kill(B *)  =  0 


gen  function 

gen(Bl)  =  def(B) 
in  all  other  cases: 

gen(B£)  =  0 


Data  flow  equations  WT 

TTZ  ,  ,  _  1 0  \Tf  init(S.) 

entry  v  |  P|{WTea,it (£')  |  (£',£)  £  flow(S+)}  otherwise 

WTeMf)  =  ((WT entry (£)  \  kill(Be))  U  gen(Be)) ,  where  Be  £  blocks(S^) 

Table  1.  Definition  of  WT  analysis.  This  is  an  intraprocedural  flow-sensitive  forward 
( F  =  flow(S *))  must  (IJ  =  P|)  analysis.  Let  def(n)  denote  the  set  of  the  variables 
updated  in  the  control  flow  graph  node  n.  See  Chapter  2  of  [NNH05]  for  understanding 
the  rest  of  the  notations  used  here. 


The  described  reduction  of  variables  from  the  argument  lists  of  loop-replacing 
functions  can  be  useful  for  proving  partial  equivalence  too. 

A. 2  Mapping  functions  with  different  numbers  of  input  arguments 

Our  normal  method  for  regression  verification  applies  a  severe  restriction  on 
function  pairs  mapped  in  mapjr :  for  functions  f  £  P  and  f  £  P' ,  (/,  f)  £ 
mapjr  only  if  /  and  f  have  the  same  list  of  formal  input  parameter  types. 
Our  method  requires  this  in  order  to  be  able  to  check  call-eciuiv(/c/ir,  f'UF). 
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kill  function 
kill(Be)  =  0 

gen  function 

gen(Bl)  =  {r>  |  v  £  use(B)  A  v  \NTentry(i)} 

Data  flow  equations  RU 

T7|  ~  7  0  if  £  =  init(S *) 

entry (  )  |  |J{ RU ea:it (£')  |  (£',£)  £  flow(S*)}  otherwise 

RU  —  ((RU  entryif)  \  kill(Be))  U  gen(B e)),  where  Bl  £  blocks(Sj,)  \ 

Table  2.  Definition  of  RU  analysis.  This  is  an  intraprocedural  flow-sensitive  forward 
( F  =  flow(S *))  may  (|J  =  |J)  analysis.  Let  use(n)  denote  the  set  of  the  variables 
which  are  read  in  the  control  flow  graph  node  n.  See  Chapter  2  of  [NNH05]  for  under¬ 
standing  the  rest  of  the  notations  used  here. 


However,  sometimes  it  is  possible  to  map  functions  with  different  number  of 
input  arguments,  as  we  will  demonstrate  in  the  following  example. 

Example  3.  Consider  two  versions  of  a  program  listed  in  Fig.  5.  Functions  h 


int  h(int  x)  { 
if  (x  <=  0) 

return  h(l  -  x); 
return  x; 

} 


int  h’(int  x’,  int  b’)  { 

if  (b’  !=  0) 
report 
if  (x’  <=  0) 

return  h’(l  -  x’,  b’); 

return  x’; 


void  report’(const  char  *s’)  { 

} 


Fig.  5.  Two  versions  of  a  program  where  functions  h  and  h!  have  different  prototypes. 


and  h'  have  different  numbers  of  input  arguments.  However,  argument  b'  affects 
neither  the  guarding  conditions  over  recursive  calls  of  h!  nor  any  value  passed 
into  those  recursive  calls  which  does  affect  them.  The  value  in  b'  has  no  influence 
on  the  future  recursive  calls  of  h! .  Thus  we  can  omit  it  from  input  comparisons 
defined  in  CallEquiv  (see  [Elel3]).  Namely,  we  can  check  call-equivalence 
between  h  and  the  function  defined  in  Fig  6. 


□ 
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int  h'i{b, }(int  x’)  { 
int  b’  =  nondet(); 
if  (b’  !=  0) 
report’ 
if  (x’  <=  0) 

return  {b,}  (1  -  x’); 
return  x’; 


Fig.  6.  Function  /i'j  ,  ,  derived  from  function  h!  (see  Fig  5)  by  removal  of  b'  from  the 
parameter  list  into  the  body  of  h! . 


In  Sect.  A. 3  we  will  formally  present  a  method  for  detecting  such  input 
arguments  as  b'  in  function  h'  from  Ex.  3.  We  coin  input  arguments  which  have 
no  influence  on  the  termination  of  their  function  termination-inert.  But  now  we 
will  describe  what  we  do  with  them  assuming  we  have  detected  them. 

We  begin  with  the  next  definition  which  we  need  for  this  description.  Given 
two  functions  /  and  f,  a  projection  of  the  parameter  list  of  f  over  the  parameter 
list  of  /  is  defined  as  follows: 

Definition  1  (7 r/).  Given  two  functions  f  and  f  such  that  the  parameter  list 
of  f  is  a  subset  of  the  parameter  list  of  f ,  and  given  a  vectorin'  of  actual  values 
passed  into  f,  define  TTf(in')  to  denote  a  reduced  version  of  in'  after  dropping 
all  the  arguments  that  have  no  match  in  the  parameter  list  of  f . 

Now  consider  two  functions  g  and  g'  such  that  g'  has  a  set  of  extra  param¬ 
eters  B'  in  comparison  with  g.  Further  assume  we  have  detected  that  all  the 
parameters  of  B'  are  termination- inert  in  g' .  We  move  them  from  the  parameter 
list  of  g'  into  the  body  of  g' ,  i.e.,  make  them  simple  local  variables  in  g'  initialized 
with  a  non-deterministic  value.  Having  updated  the  parameter  list  of  g' ,  we  also 
need  to  update  all  the  calls  of  g'  correspondingly  in  the  whole  program  where  g' 
was  defined. 

Definition  2  (/jB).  Given  function  f  in  program  P  and  a  set  B  of  this  func¬ 
tion’s  input  parameters,  define  /jB  to  denote  the  function  derived  from  f  by: 

—  moving  the  elements  of  B  from  the  parameter  list  of  f  into  the  body  of  f; 

—  initializing  them  with  non-deterministic  values; 

—  replacing  all  the  calls  to  f  in  P  with  corresponding  calls  to  f\B. 

An  example  of  a  function  derived  in  this  manner  is  given  in  Fig.  6.  Note  that 
for  non-empty  B,  function  /jB  is  non-deterministic.  We  must  refine  the  earlier 
definitions  of  termination  and  mutual  termination  in  order  to  apply  them  to 
non-deterministic  functions. 

—  Termination.  Let  term(f  (in))  denote  the  fact  that  f(in)  terminates  for  all 

its  possible  computations. 
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—  Non-termination.  Let  non-term(f  (in))  denote  the  fact  that  there  is  no  pos¬ 
sible  computation  of  f(in)  which  terminates.  Note  that  for  deterministic 
functions  non-term((f  (in)))  =  -i term(f(in)).  However,  the  latter  is  not 
necessarily  true  for  non-deterministic  functions.  Therefore,  we  need  to  rede¬ 
fine  m-term. 

—  Mutual  termination.  If  either  function  /  or  function  /'  (or  both)  is  non- 
deterministic,  then  their  mutual  termination  is  defined  as  follows: 

m-term(f ,  f)  =  Win.  ((term(f  (in))  o  term(f  (in)))  A 

(non-term(f  (in))  -(-A  non-term(f' (in))))  . 


Once  we  have  achieved  that  the  prototypes  of  the  discussed  functions  g  and 
g’ j  match,  we  can  check  m-term(g ,  g' j  ) .  But  as  far  as  the  mutual  termination 
of  g  and  g'  matters,  the  definition  of  m-term  requires  the  same  parameters  in 
both  g  and  g' .  We  need  to  address  the  extra  parameters  of  g'  in  the  following 
refinement  of  the  definition  of  mutual  termination. 

Definition  3  (Mutual  termination  of  functions  with  respect  to  projec¬ 
tion  of  parameter  list).  Two  deterministic  functions  f  and  f  are  mutually 
terminating  with  respect  to  a  subset  of  inputs  if  and  only  if  for  any  input  in  of 
f  and  any  input  in'  of  f,  the  following  holds: 

in  =  TTf(in')  — >  (term(f(in))  -B  term(f  (in')))  . 

Let  m-term^f  (/,  /')  denote  the  fact  that  /  and  f  mutually  terminate  with 
respect  to  a  subset  of  inputs.  The  following  inference  rule  allows  to  derive  a 
conclusion  about  m-term^g  (g,  g'): 


(/,  /'}  €  mapjr  A  m-term(f,  f\  b,  ) 
m-term^f  (/,  /') 


(m-term-7t)  , 


(1) 


where  B'  is  the  subset  of  the  input  parameters  of  f  missing  in  7 Tf.  A  proof  of 
its  soundness  appears  in  [Elel3]. 

Note  that  the  modifications  which  created  g' j  do  not  necessarily  preserve 
the  semantics  of  g' .  Consequently,  checking  m-term(g,  g' j  )  usually  involves 
different  uninterpreted  functions. 


Example  4.  Reconsider  functions  h  and  h'  listed  in  Fig  5.  Parameter  b '  of  the 
prototype  of  h!  is  a  termination- inert  input  argument.  It  can  be  excluded  from 
the  parameter  list  of  h! .  Function  /i'j{6,},  listed  in  Fig  6,  and  h,  defined  in  Fig  5, 
have  the  same  prototype.  Now  RVT  can  prove  m-term(h,  h' \  {i/} )  and  infer2 
m-termnh  (h,  h'). 

2  In  practice,  RVT  does  not  make  the  minute  formal  distinction  between  m-term  and 
m-termnf  in  its  output.  They  are  reported  in  the  same  manner. 
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A. 3  Detecting  termination-inert  input  arguments. 


An  algorithm  for  checking  whether  a  given  argument  v  of  function  /  is  a  termination- 
inert  input  argument  of  /  consists  of  two  stages.  First,  it  builds  a  System  Defi¬ 
nition  Graph  [HRB90]  (SDG)  for  program  P  where  /  is  defined. 

Briefly,  an  SDG  is  an  extension  of  a  Program  Dependence  Graph  [FOW87,KKP+81] 
(PDG)  for  multi-function  programs.  The  original  nodes  of  some  function’s  PDG 
represent  the  statements  of  the  function.  The  edges  of  the  PDG  represent  data 
and  control  dependencies  between  the  statements  of  the  function  and  thus  define 
their  partial  order:  the  semantics  of  the  function  is  preserved  if  its  statements 
are  executed  in  this  order. 

An  SDG  consists  of  PDGs  for  each  function  of  the  program  plus  the  following 
additions.  Each  function  g  of  the  program  is  associated  with  an  entrance  node 
”  Enter  g" .  For  each  input  argument  u  of  this  function,  the  SDG  contains  a  node 
of  type  u  =  Uing  and  an  edge  entering  this  node  and  leaving  node  ”  Enter  g" . 

Each  node  representing  a  call  to  function  g  has  a  leaving  edge  entering  the 
entrance  node  of  g ,  i.e. ,  ” Enter  g" .  In  addition,  for  an  expression  expr  passed 
as  parameter  u  in  that  call,  there  are  a  node  of  type  Uin  =  expr  with  the  two 
following  edges: 

—  an  entering  edge  which  leaves  that  function-call  node,  and 

—  a  leaving  edge  which  enters  the  recently  mentioned  node  of  type  u  =  Uing . 

The  return  value  of  g  has  its  own  dedicated  node  retvalg.  Its  entering  edges 
leave  nodes  whose  statements  affect  the  return  value.  Its  leaving  edges  enter 
nodes  whose  statements  depend  on  the  return  value.  Fig.  7  demonstrates  an 
example  of  an  SDG  built  for  the  sub-program  starting  in  function  h'  from  Fig  5. 

At  the  second  stage  the  algorithm  checks  whether  any  of  the  calls  to  function 
/  is  reachable  from  node  v  =  Vinf ,  where,  recall,  v  is  the  name  of  the  given  input 
argument.  If  none  is  reachable,  then  argument  v  is  a  termination-inert  input 
argument  of  /.  The  algorithm  is  presented  in  Alg.  1. 

Example  5.  Regard  the  SDG  in  Fig.  7,  built  for  the  sub-program  starting  in 
function  h’  from  Fig  5.  It  has  no  node  of  a  function  call  to  h'  which  is  reachable 
from  node  b1  =  b'in  t .  Hence,  b'  does  not  affect  any  guarding  condition  over  any 
recursive  call  to  h! . 


Algorithm  1  Algorithm  for  checking  whether  an  input  argument  is  termination- 
inert. _ 

1:  function  IsCALLEQUlvlNERT(Program  P,  function  /,  argument  v) 

2:  Build  an  SDG  for  P; 

3:  for  each  call  to  /  in  this  SDG  do 

4:  if  this  call  is  reachable  from  node  v  =  Vin ,  then  return  FALSE; 

5:  return  true; 
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Fig.  7.  The  System  Definition  Graph  [HRB90]  of  the  sub-program  starting  in  function 
h! ,  defined  in  Fig  5. 
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A. 4  Partial  equivalence  with  respect  to  a  subset  of  outputs 

The  improvement  reported  in  this  section  refines  the  output  of  the  decomposition 
algorithm  for  checking  partial  equivalence  [GS11]. 

Recall  that  C  functions  may  have  multiple  outputs,  and  that  so  far  we  defined 
partial  equivalence  with  respect  to  all  of  them,  i.e.,  given  the  same  inputs,  the  two 
functions  are  equivalent  in  all  output  elements  pair-wise.  However,  sometimes  the 
equivalence  of  some  of  the  outputs  is  sufficient  for  proving  mutual  termination. 

Example  6.  Consider  the  functions  listed  at  the  top  of  Fig.  8.  Formally,  g  and  g' 
are  not  partially  equivalent  because  different  values  are  assigned  into  p  and  p', 
which  are  among  the  outputs  of  g  and  g' ,  respectively.  But  the  return  values  of 
g  and  g'  are  equivalent.  This  fact  could  be  useful  for  establishing  m-term(g,  g'). 


int  g(int  x,  int  *p)  { 

if  (x  <  5  ||  p  ==  NULL) 
return  0; 

*P  =  0; 

g(g(x-  1,  p),  NULL); 

return  0; 

} 

int  g’(int  x’,  int  *p’)  { 

if  (x’  <  5  ||  p’  =4  NULL) 

return  0; 

V  =  i; 

g’(g’(x’  -  1,  p’),  NULL); 

return  0; 

} 

int  gUF( int  x,  int  *p)  { 

int  g'UF( int  x’,  int  *p’)  { 

if  (x  <  5  ||  p  ==  NULL) 

if  (x’  <  5  ||  p’  ==  NULL) 

return  0; 

return  0; 

*P  =  0; 

V  =  l; 

UFg(UFg(x  -  1,  p),  NULL); 

UF',(UF',(x’-l,  p’),  NULL); 

return  0; 

return  0; 

} 

} 

Fig.  8.  Two  versions  of  functions  which  are  partially  equivalent  with  respect  to  their 
return  values  (at  the  top)  and  their  isolated  versions  (at  the  bottom). 


Consider  gUF  and  g'UF  listed  at  the  bottom  of  Fig.  8.  The  obstacle  for 
proving  call-equiv(gUF ,  g,UF)  is  the  fact  that  given  the  same  inputs,  UFg  and 
U F'g,  are  not  enforced  to  produce  the  same  return  values.  But  we  may  enforce 
the  equivalence  of  the  return  values  of  UFg  and  UF'g,  only,  because  g  and  g'  are 
partially  equivalent  with  respect  to  their  return  values. 

□ 


Let  out(f)  denote  the  list  of  output  elements  that  function  /  produces. 

Definition  4  (Partial  equivalence  of  functions  with  respect  to  paired 
elements  of  the  outputs).  Two  functions  f  and  f  are  partially  equivalent 
with  respect  to  (o,  o')  such  that  o  €  out(f)  A  o'  €  out(f)  if  any  two  terminating 
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executions  of  f  and  f  starting  from  the  same  inputs,  produce  the  same  values 
for  o  and  o' . 

Let  p-equiv (0t0i)  (/,/')  denote  the  fact  that  /  and  /'  are  partially  equivalent  with 

respect  to  (o,  o').  For  given  o  £  out(f)  and  o'  £  out(f'),  let  /  °’°  f  denote  the 
fact  that  given  the  same  inputs  /  and  f  produce  the  same  values  for  o  and  o' , 
respectively. 

When  RVT  is  activated  for  checking  partial  equivalence,  it  first  attempts  to 
establish  p-equiv(f,  f)  for  each  (/,  f)  which  it  is  checking.  Only  if  it  fails  to  have 
proven  this,  it  checks  the  equivalence  of  output  elements  one  by  one.  For  each 
pair  of  output  elements  (o,  o')  with  respect  to  which  partial  equivalence  could 
be  proven,  it  assigns  label  part-eq^0)0')  to  (/,  /').  Thereby  it  finds  a  maximal 
mapping  {(o,  o')  |  o  £  out(f)Ao'  £  out(f')  A  p-equiv (0,0')(f ,  f')} ■  This  mapping 
can  be  also  useful  when  the  outputs  of  /  cannot  be  bijectively  mapped  with  the 
outputs  of  /'. 

Now  we  can  refine  (enforce-1)  (see  ([Elel3])): 

U  Ff  ==  U  F'f,  =>  ((/,  f)  £  mapj -  A  p-equiv <0>0/)  (/,  /'))  (enforce-2)  (2) 

We  refine  the  implementation  of  Uf’  in  a  manner  compatible  with  this  condition, 
i.e. ,  given  the  same  inputs,  the  values  of  o  and  o'  are  the  same  when  (/,  f)  is 
labeled  part_eq^0^).  Otherwise,  the  values  of  the  output  elements  need  not  be 
the  same.  The  refined  implementation  of  UF’  is  shown  at  the  bottom  of  Fig.  9. 

B  New  proof  methods 

In  this  appendix,  we  list  several  research  direction  that  we  currently  investigate, 
all  of  which  are  targeted  towards  finding  ways  to  prove  equivalence  in  cases  that 
our  current  methods  fails.  Hence,  it  is  also  targeted  towards  completeness.  The 
methods  are  based  on  computing  weakest-preconditions  and  fc-induction. 

B.l  Using  Weakest  Pre-Condition  information 

Before  we  overview  the  calculation  of  a  WP,  we  shall  recall  the  definition  of  a 
Hoare  Triplet  {Q}S'{i?}.  This  notion  states  that  when  a  pre-condition  Q  holds 
before  the  execution  of  S  then  after  the  execution  of  S  the  predicate  R  will 
be  evaluated  to  true.  A  program  statement  can  be  viewed  as  a  state  trans¬ 
former  which  transforms  a  pre-condition  to  a  post-condition.  We  calculate  a 
pre-condition  by  transforming  the  post-condition  each  statement  at  a  time  back¬ 
ward  starting  from  the  termination  point.  We  shall  now  overview  some  of  the 
possible  statements  and  how  to  transform  the  predicates.  The  following  two  lines 
of  code  illustrate  the  calculation: 

i=z+4; 


z=i+z  *  2; 
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1:  function  UF(function  index  g,  input  parameters  in)  t>  Called  in  side  0 

2:  if  in  G  params[g ]  then  return  the  output  of  the  earlier  call  UF (g,  in); 

3:  params[g]  :=  params[g]  [J  in; 

4:  return  a  non-deterministic  output; 

5:  function  UF’(function  index  g',  input  parameters  in')  [>  Called  in  side  1 

6:  if  in'  G  params[g']  then  return  the  output  of  the  earlier  call  UF’(g',  in'); 

7:  params[g'\  :=  params[g']  (J  in'; 

8:  if  in'  G  params[g]  then  >  { g,g ')  G  map ^ 

9:  result  :=  []; 

10:  for  each  Oi  G  out(g)  do  t>  o\  G  out(g’) 

11:  if  {<?,(/}  is  marked  as  part_eq  or  as  part-eq^0iy,)  then 

12:  append  the  result  for  Oi  of  the  earlier  call  UF(g,  in')  to  result; 

13:  else  append  a  non-deterministic  value  to  result; 

14:  return  result; 

15:  assert(O);  t>  Not  call-equivalent:  params[g'\  2  params[g\ 

Fig.  9.  Implementations  for  functions  UF  and  uf’,  where  the  latter  takes  into  consider¬ 
ation  partial  information  about  partial  equivalence.  UF  and  uf’  emulate  uninterpreted 
functions  if  instantiated  with  functions  that  are  mapped  to  one  another,  and  form  a 
part  of  the  generated  program  5,  as  shown  in  CallEquiv  (see  [Elel3])  or  in  the  de- 
terminization  thereof.  These  functions  also  contain  code  for  recording  the  parameters 
with  which  they  are  called. 
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Our  desired  post-condition  is  2  >  i  +  3.  We  sequentially  calculate  the  WP. 
First  we  calculate  the  pre-condition  of  the  second  statement: 

3 

WP(z=i  +  z*2,z>i  +  3)  =  z>  — 

.  Finally  we  will  calculate  the  pre-condition  of  the  first  statement: 


WP 


=  z  +  4,  z  > 


We  received  our  pre-condition.  Let  us  examine  another  example  which  includes 
a  conditional  statement: 

if  (res  “/«  2  ==  0) 
res  =  res  -  1; 

else 

res  =  res  +  1 ; 

Our  desired  post-condition  is  res  >  0.  We  receive: 

WP  ( S ,  res  >  0)  =  ((res% 2  ==  0)  =>■  WP  ( res  =  res  —  1,  res  >  0))  A 


(-i  {res% 2  ==  0)  =>  WP  ( res  =  res  +  1,  res  >  0))  =  ((res% 2  ==  0)  =>  res  >  1)  A 


(-i  ( res%2  ==  0)  =$■  res  >  —  1) 


Motivating  example  Consider  the  following  two  programs: 


int  fO(int  x){ 
if  (x  <=  OH 
return  1 ; 

} 

int  res  =  fO(x-l); 
if  (res  <  0)  return  3; 
else  return  2; 

> 

Fig.  10. 


int  fl(int  x){ 
if  (x  <=  OH 
return  1 ; 

> 

int  res  =  fl(x-l); 
if  (res  <  0)  return  1; 
else  return  2; 

} 

two  compared  functions. 


Both  / 0  and  / 1  are  equivalent.  One  might  claim  that  in  case  the  variable 
res,  which  is  the  result  of  the  recursive  call,  might  return  a  negative  value  and 
cause  the  result  value  of  the  two  functions  to  be  different.  However  a  closer 
examination  would  reveal  that  both  functions  never  return  a  negative  result  and 
so  the  expression  res  <  0  always  evaluates  to  false.  Now  we  would  like  to  prove 
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int  fO(int  xM 
if  (x  <=  OH 
return  1 ; 

} 

int  res  =  UF_fO(x-l); 
if  (res  <  0)  return  3; 
else  return  2; 

> 


int  fl(int  x){ 
if  (x  <=  OH 
return  1 ; 

> 

int  res  =  UF_fl(x-l); 
if  (res  <  0)  return  1 ; 
else  return  2; 


Fig.  11.  The  two  functions  of  Fig.  10,  after  the  function  calls  are  replaced  with  calls 
to  the  same  UF. 


the  equivalence  of  the  two  functions  using  uninterpreted  function  abstraction. 
We  do  this  by  replacing  the  recursive  calls  of  / 0  and  /I  to  their  matching 
uninterpreted  functions  UF_fO  and  UF_fl. 

Running  CBMC  to  perform  the  equivalence  proof  requires  the  following  main 
function: 


int  main (void) { 

int  in,  outO,  outl; 
outO  =  fO(in); 
outl  =  f 1 (in) ; 
assert(outO  ==  outl); 
return  0 ; 

> 


Fig.  12.  The  main  function  calls  / 0  and  / 1  with  a  nondeterministic  input,  and  com¬ 
pares  their  return  values. 


CBMC  will  output  a  failure  when  asserting  the  claim  above.  This  example 
manifests  the  incompleteness  of  this  method.  Abstracting  away  our  function  calls 
to  uninterpreted  functions  has  resulted  in  information  loss:  the  UF’s  do  not  keep 
the  positive  return  value  property.  Whenever  an  assertion  fails  CBMC  generates 
a  counterexample.  In  this  case,  examining  the  counterexample  will  demonstrate 
the  root  cause  of  the  failure:  the  UF’s  had  returned  negative  values.  In  the  next 
section  I  shall  propose  two  methods  to  preserve  information  in  some  cases  while 
abstracting  recursive  calls  to  UF’s. 

Proposed  Solutions  In  this  section  I  will  describe  two  approaches  which  can 
assist  in  enlarging  the  set  of  partially  equivalent  program  pairs  that  we  can  prove 
and  thus  improve  completeness. 

Strengthening  UFs  using  weakest  pre-condition  In  Figs.  10  and  12  we 

encountered  two  partially  equivalent  programs.  However  our  original  method 
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failed  to  prove  their  equivalence.  Now  we  shall  attempt  to  solve  this  problem 
using  WP  predicates.  The  assertion  in  Fig.  12  is  the  desired  post  condition  of 
partial  equivalence.  By  calculating  the  weakest  pre-condition  as  described  in 
section  B.l  we  can  conclude  that  the  weakest  pre-condition  required  from  the 
the  result  of  the  UFs  in  Fig.  11  is  res/o  >  0  A  res/i  >  0 
We  shall  formulate  the  following  proof  rule: 

p-equiv(ccd?  /,  call  f)  A  WP  \~h  p-equiv(cod?  /,  call  /')  A  WP 
p-equiv(coiZ  /,  call  f)  A  WP 

The  proof  rule  is  very  similar  to  the  proof  rule  at  figure  ??  with  the  addition  of 
the  conjunction  with  the  WP  formula.  This  conjunction  is  used  to  strengthen 
our  induction.  Let  us  return  to  our  example  and  show  how  the  new  strengthened 
proof  rule  is  used  when  translated  to  code.  First  we  remind  that  uninterpreted 
functions  keep  the  premise  of  the  partial  equivalence  rule  as  shown  in  [GS08]. 
Now  we  add  to  our  code  the  WP  premise.  We  add  the  required  weakest  pre¬ 
condition  assumption  to  both  our  functions.  By  adding  the  weakest  pre-condition 
we  receive  the  following  code: 


int  fO(int  xH 
if  (x  <=  OH 
return  1 ; 

} 

int  res  =  UF_fO(x-l) ; 
assume (res  >=  0); 
if  (res  <  0)  return  3; 
else  return  2; 

> 


int  fl(int  x){ 
if  (x  <=  0){ 
return  1 ; 

> 

int  res  =  UF_fl(x-l); 
assume (res  >=  0); 
if  (res  <  0)  return  1 ; 
else  return  2; 

} 


Fig.  13.  The  two  functions  of  Fig.  11,  after  adding  the  weakest  pre-condition  predicate 
as  an  assumption 


To  have  a  consistent  inductive  proof  rule  we  must  also  alter  the  main  function 
in  the  following  way: 

int  main(){ 

int  n,  resO,  resl; 
retO  =  f0(n) ; 
retl  =  f 1 (n) ; 

assert (retO  ==  retl  &&  retO  >  0  kk  retl  >  0); 
return  0 ; 

> 


CBMC  returns  ‘verified’  on  these  two  functions,  hence  we  were  able  to  prove 
the  step  of  the  induction.  If  we  examine  the  process  of  calculating  the  WP 
formula  more  closely  we  can  see  that  we  start  with  a  premise  that  both  function 
output  the  same  value  and  calculate  the  required  condition  that  must  hold  at 
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a  certain  point  in  the  code  so  that  the  premise  will  be  true.  From  this  we  can 
conclude  the  following  relation:  out  ==  out'  4=>  WP.  It  is  obvious  that  we  can 
remove  the  equality  assertion  and  still  receive  the  same  result. 


B.2  FC-Induction 


The  standard  induction  proof  rule  over  the  natural  numbers  can  be  formulated 
as  follows: 

P( 0)  -4-  (VnP(n  -  1)  -)•  P(n)  -4-  VnP(n))  ,  (3) 

where  P  is  the  formula  we  wish  to  prove. 

A  generalization  called  k- induction,  was  proposed  by  [SSS00] : 


k- 1 


/k-i 


P(i)  A  Vn  I  I  yy  P(n  +  *)  1  — »  P(n  +  fc)  )  — >•  VnP(n)  . 


(4) 


i=0 


vi— 0 


Note  that  this  formula  is  a  generalization  of  (3)  when  k  =  1.  We  propose  to  use 
fc- induct  ion  in  order  to  improve  the  completeness  of  regression  verification. 


Implementing  IT-Induction  Recall  the  two  functions  in  Fig.  10,  and  their 
abstraction  in  Fig.  11.  Recall  that  the  abstract  version  was  too  abstract,  which 
prevented  us  from  proving  partial  equivalence.  Let  us  attempt  to  solve  this  prob¬ 
lem  using  2-Induction. 


int  f0_2(int  xH 
if  (x  <=  OH 
return  0 ; 

} 

int  res ; 

res  =  UF_fO(x-l); 
if  (res  <  0)  return  3; 
else  return  2; 

> 


int  fl_2(int  x){ 
if  (x  <=  OH 
return  0 ; 

> 

int  res ; 

res  =  UF_fl(x-l); 
if  (res  <  0)  return  1; 
else  return  2; 

} 


int  f0_l(int  xH 
if  (x  <=  OH 
return  0 ; 

} 

int  res  =  f0_2(x-l); 
record_out_f 0_2  =  res; 
if  (res  <  0)  return  3; 
else  return  2; 

> 


int  fl_l(int  x){ 
if  (x  <=  OH 
return  0 ; 

> 

int  res  =  fl_2(x-l); 
assume (res  ==  record_out_f0_2) ; 
if  (res  <  0)  return  1; 
else  return  2; 


Fig.  14.  The  programs  of  Fig.  11,  unrolled  twice. 
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In  Fig.  14  we  have  unrolled  the  two  functions  twice.  We  say  that  /0_1  and 
/1_1  are  a  first  level  functions  and  / 0_2  and  / 1_2  are  a  second  level  functions. 
The  functions  on  the  first  level  call  their  matching  functions  on  the  second  level 
and  the  second  level  functions  call  the  matching  UFs. 

In  section  ??  we  mentioned  that  when  proving  the  inductive  step,  the  in¬ 
ductive  assumption  is  implemented  by  the  UFs,  however  to  prove  the  induction 
step  with  2-induction  we  will  need  another  level  of  assumption.  We  implemented 
this  using  another  assumption  in  both  /0_1  and  /1_1  which  assumes  the  equality 
of  the  results  in  the  first  level.  We  implemented  this  using  the  global  variable 
record-out-f  0_2  which  records  the  result  of  side  0  in  the  second  level. 

B.3  Combining  iT-Induction  and  weakest  pre-condition 

Combining  both  methods  may  improve  completeness  even  further.  We  implement 
this  by  replacing  the  equivalence  assumption  with  the  weakest  pre-condition 
predicate.  Fig.  15  exhibits  this.  Note  that  the  UFs  no  longer  supply  us  with 
the  required  inductive  step  assumption  and  therefor  we  must  add  an  additional 
assumption. 


int  f0_2(int  xH 
if  (x  <=  0)f 
return  0 ; 

} 

int  res; 

res  =  UF_fO(x-l); 
assume (res  >  0) ; 
if  (res  <  0)  return  3; 
else  return  2; 

> 

int  f0_l(int  xH 
if  (x  <=  OH 
return  0 ; 

} 

int  res  =  f0_2(x-l); 
assume (res  >  0) ; 
record_out_f 0_2  =  res; 
if  (res  <  0)  return  3; 
else  return  2; 

> 


int  fl_2(int  x){ 
if  (x  <=  OH 
return  0 ; 

> 

int  res ; 

res  =  UF_fl(x-l); 
assume (res  >  0); 
if  (res  <  0)  return  1 ; 
else  return  2; 

} 

int  fl_l(int  x){ 
if  (x  <=  OH 
return  0; 

> 

int  res  =  fl_2(x-l); 
assume (res  >  0); 
if  (res  <  0)  return  1; 
else  return  2; 

} 


Fig.  15.  The  programs  of  Fig.  14  with  weakest  pre-condition  assumptions. 


When  combining  the  two  methods  we  must  separate  the  base  case  proof  from 
the  inductive  step  proof.  Our  original  method  will  succeed  in  proving  the  partial 
equivalence  of  the  two  functions  in  Fig.  16  even  though  they  are  not  equivalent 
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due  to  the  negative  return  value.  This  proof  doesn’t  fail  as  it  should  because  the 
weakest  pre-condition  assumption  blocks  all  paths  where  the  UFs  can  return  a 
negative  value. 

We  prove  our  base  case  step  by  making  two  transformations  to  our  original 
method.  First  we  convert  all  UF  calls  back  to  recursive  calls.  We  do  this  by 
adding  a  new  global  boolean  variable  base,  when  verifying  the  base  case  its 
value  is  true  and  false  otherwise.  The  mechanism  is  displayed  in  the  following 
code: 


if  (base)  res  =  fO_l(x-l); 
else  res  =  UF_fO(x-l); 

Second  when  the  base  variable  is  set  to  true  we  limit  CBMC  to  unwind  the 
recursion  to  k  and  run  it.  Now  CBMC  will  explore  all  k  level  base  cases.  In 
Fig.  17  we  can  see  the  functions  from  Fig.  16  modified  to  handle  the  base  case 
proof.  CBMC  indeed  returns  ’un-verified’  when  given  the  modified  functions. 


int  fO(int  xH 
if  (x  <=  OH 
return  1 ; 

} 

int  res  =  UF_fO(x-l) ; 
assume (res  >=  0); 
if  (res  <  0)  return  3; 
else  return  -1; 

> 


int  fl(int  x){ 
if  (x  <=  OH 
return  1 ; 

> 

int  res  =  UF_fl(x-l); 
assume (res  >=  0); 
if  (res  <  0)  return  1 ; 
else  return  -1; 


} 

Fig.  16.  The  two  functions  of  Fig.  11  with  a  negative  return  value. 


int  f0(int  xH 
if  (x  <=  OH 
return  1 ; 

} 

if  (base)  res  =  f0_2(x-l); 
else  res  =  UF_fO(x-l); 
if  (!base)  assume (res  >=  0) ; 
if  (res  <  0)  return  3; 
else  return  -1; 

> 


int  fl(int  x){ 
if  (x  <=  OH 
return  1 ; 

> 

if  (base)  res  =  fl(x-l); 
else  res  =  UF_fl(x-l); 
if  (!base)  assume (res  >=  0) 
if  (res  <  0)  return  1 ; 
else  return  -1; 

} 


Fig.  17.  The  two  functions  of  Fig.  16  with  base  case  handling  code. 
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B.4  Comparing  /^-Induction  and  weakest  pre-condition 

In  my  thesis  I  would  like  to  explore  the  relation  between  the  WP  method  and 
the  fc- induct  ion  partial  equivalence  proof  method.  In  the  example  shown  be¬ 
fore  their  strength  is  equal.  While  1-induction  was  unable  to  prove  what  WP 
managed  to  prove,  2-induction  was  sufficient.  Another  interesting  topic  is  the 
relation  between  different  characteristics  of  the  program  and  the  required  level 
of  induction:  can  this  level  be  computed?  can  we  compute  a  bound  on  this  level? 

B.5  K\,  K-2,  Induction 


int  fl(int  x){ 
nl++ ; 

if  (x  <=  1)  return  0; 
int  res  =  fl(x  -  1)  +  1; 
return  res ; 

> 


int  f2(int  x){ 
n2++; 

if  (x  <=  1)  return  0; 
x — ; 

if  (x  <=  1)  return  1; 
int  res  =  f2(x  -  1)  +  2; 
return  res; 


} 


Fig.  18.  Two  equivalent  recursive  programs  that  iterate  a  different  number  of  times 
given  the  same  input. 


Consider  the  example  in  Fig.  18.  It  shows  an  optimization  called  Loop  Un¬ 
winding,  in  a  recursive  function  format.  This  optimization  may  result  in  several 
benefits  such  as  reduced  branch  prediction  penalties,  better  parallelization,  and 
more.  These  optimizations  can  be  produced  automatically  by  the  compiler  or 
manually.  Often  we  would  like  to  check  partial  equivalence  between  two  similar 
functions  where  one  is  some  sort  of  an  unwinding  optimization  of  the  other. 

Our  previous  method  of  fc- induct  ion  will  fail  to  prove  the  equivalence  of  the 
two  previous  functions  because  the  bodies  of  the  functions  are  not  equivalent 
and  also  the  recursive  calls  on  each  side  are  different.  However  if  we  can  receive 
the  relation  between  the  unrolling  of  the  functions  from  the  optimizer  we  can 
use  it  to  perform  a  K i  —  K2  induction. 
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